home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part2 / 12758 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.1 KB

  1. Path: news.sprintlink.net!datalytics!usenet
  2. From: Rob Stewart <stew@datalytics.com>
  3. Newsgroups: comp.lang.c,comp.programming
  4. Subject: Re: Assertive or Defensive?
  5. Date: Tue, 02 Apr 1996 12:51:45 -0500
  6. Organization: Datalytics, Inc
  7. Message-ID: <31616931.2469@datalytics.com>
  8. References: <4ioggn$3sf@dazzle.east-tenn-st.edu>
  9.         <4itcs2$po3@B1FF.mindspring.com> <31546257.11E1@olympic.net> <htlokjqx7y.fsf@calph.physics.sunysb.edu>
  10. NNTP-Posting-Host: 204.62.224.71
  11. Mime-Version: 1.0
  12. Content-Type: text/plain; charset=us-ascii
  13. Content-Transfer-Encoding: 7bit
  14. X-Mailer: Mozilla 2.0 (WinNT; I)
  15.  
  16. Eugene Tyurin wrote:
  17. > Basically, they say: we have 2 versions of code -- development and
  18. > production (they call it "slick").  Production version has minimum of
  19. > diagnostics, because who cares if a program crashes once in a while
  20. > instead of exiting with proper message -- user can always reboot.
  21.  
  22. You must carefully select when to use assertions and when to use 
  23. runtime validation.  If you test your debug version of the 
  24. software, you'll discover the mistakes and misuse of things.  
  25. The code thus helps you correct bugs before you ship the 
  26. product.  This is far preferable to a program that reports 
  27. an error that says, in effect, "One of our developers made a 
  28. mistake by passing that value to this function.  You'll have to 
  29. notify our technical support department, then wait for our next 
  30. patch or upgrade--for which you'll probably need to pay--to get 
  31. the correction."
  32.  
  33. You can even use an assertion to call attention to error 
  34. handling in your code.  For example, say you expect that a 
  35. certain condition won't occur in a proper program, but can't be 
  36. certain of it.  Furthermore, suppose that the results of that 
  37. condition are disastrous.  You can code an assertion to call 
  38. attention to the mistake, but also code runtime handling of the 
  39. error.  This prevents the production version of the program from 
  40. crashing, but also catches most circumstances in which the 
  41. erroneous value was given.
  42.  
  43. You can't eliminate runtime error checking.  There are some 
  44. conditions that you simply can't account for.  You must, 
  45. therefore, choose what can be eliminated through the use of 
  46. assertions and debugging, and what cannot.
  47.  
  48. > Last time I used assert was to detect numerical overflow.  I found the
  49. > problem and corrected it.  After that assert became redundant.
  50.  
  51. If you ever change (or someone else changes) your code for 
  52. maintenance reasons, the assertion will still be there to tell 
  53. you when you've introduced the problem again.  Of course, if you 
  54. have a test driver for each function to supply inputs that test 
  55. all aspects of your function and validate its processing, AND 
  56. you use it whenever you make changes, then you don't need an 
  57. assertion to detect the problem.
  58.  
  59. When writing code shared by many developers, assertions can 
  60. communicate and enforce one developer's intention as to what 
  61. should enter or leave a function.  Furthermore, assertions can 
  62. help you ensure that the intermediate steps are consistent with 
  63. your goal.
  64.  
  65. -- 
  66. Robert Stewart        | My opinions are usually my own.
  67. Datalytics, Inc.    | stew@datalytics.com
  68.